1. Field of the Invention
This invention pertains generally to software application programs requiring multiple language support. More particularly this invention is directed to an improved system and method for providing multiple language support to an application having a remote language database.
2. The Prior Art
Application programs that are expected to be used by persons speaking different languages require multiple language support. This requirement falls on all applications having any type of user interface, from older character-cell based user interfaces to the most current graphical display user interfaces. In each case, there will be text displayed that must be in the language of the user. In some cases multiple languages will be in use at the same time.
Initially application programs were rewritten for each target language. This solution required a separate code base for each target language. Having multiple code bases for a single application creates problems. Considerable logistical complexity is created when there are multiple code bases. Multiple code bases also create significant maintenance problems because of the coordination and propagation of changes between multiple parallel development efforts. The separate code base solution proved prohibitively expensive for continuing multilingual distribution of applications.
The next solution in providing multilingual support avoided the multiple code base problems by introducing a single code base with different software modules that contained language text strings. Text strings, and other variables used by the program, are all placed in one location. This location, a separate module and often a separate file, gets compiled into the final program and contains text strings for all the places in the user interface that have textual portions in the display. Files containing variables needed during the execution of a program are sometime called environmental files, and generally contain data that is expected to be changed during the life of the program with more frequency than the code base. Depending on the application text strings where kept in separate modules, files, or with other data in environmental files.
In the case of providing different language support, modules would include text strings from one or more languages that are to be used in the user interface, or could have a different language module for each supported language. These files are then built-in to the application program by being part of the program build, or being in the complied version of the program. Thus, the application is built using specified language modules or files whose contents may vary depending on the compiled program""s target audience.
The physical topology of computer systems used for the two multilingual support solutions just discussed were the large, centralized computers predominant one to two decades ago. In such installations there would be a computer or set of computers in a centralized location, examples being IBM 360s or CDC Cyber 6000s. User interface equipment consisted of hardwired terminals, coupled with the central computers using MUXes and similar equipment. As a result of the physical architecture, all the software on this system is colocated with the central computer or computers. Everything from the operating system to the application is on one machine or a closely coupled set of machines in close physical proximity with dedicated high-speed system interconnects.
As network technology matured typical system topology evolved, changes began occurring in typical systems topologies, especially at the front-end connections to the traditional computer rooms. There was still a central computer or cluster of computers which typically had a relatively large amount of secondary storage, including any databases, connected directly to the centralized computers. Example computers would include mainframes such as DEC VAX 8000 series or IBM 390 series, or xe2x80x9cmidixe2x80x9d machines such as DEC VAX 6000-series. The significant changes were occurring at the system""s front-end. Terminals were now typically connected through a LAN rather than through dedicated terminal connections. An example of such a connection is DEC""s LAT protocol running on an Ethernet-based LAN. In addition small local LANs having a relatively small number of individual systems, mostly IBM PC""s or clones running some version of MS-DOS, were connected through the LANs to the centralized systems. Applications were typically terminal emulators with character-cell based applications, or with very limited graphics.
The physical system topology just discussed had the property of maintaining large or complex application programs on the central computer systems because the smaller systems didn""t have the computing capability nor the storage capability to run larger applications. Networks were relatively slow, and the user interfaces where virtually all character-cell based.
Referring again to multilingual support for software that was evolving along with the hardware, the use of a single code base with language modules took care of the maintenance problems found with multiple code bases. Other limitations still existed, however. When language modules are compiled into an application, changes to the language files require recompiling and reinstalling the program. Thus when changes occurred the program would have to be stopped, perhaps uninstalled, and the newly compiled version installed. In addition to being a fair amount of work for the system administrators, this necessitated periods of time when the application wasn""t available (xe2x80x9cdown-timexe2x80x9d). Down-time was expected, even if barely tolerated, when most applications ran on main-frames inside of computer centers. The issue became increasingly problematic as the availability of smaller, individualized, local systems came into increasingly common use. As more machines were being used by people not disciplined or tolerant in the ways of the centrally controlled main-frames with their scheduled downtimes, users pushed for no down time. No down-time is often characterized by the system""s availability in hours (up to 24) and days (up to 7); no down-time corresponds to all-hours, all-days availability or 24xc3x977 availability.
At the same time, application developers were making increasing use of databases to support multilingual applications. This meshed with the increasing need for 24xc3x977 availability for applications having multilingual capabilities. Using a database allows the application to stay up regardless of what was happening to the database. It allows for changes to be made to the database independently from the running application, and allowed very substantial changes to made to the data stored in data bases without affecting the running application. If a switch-over from one set of data to another was needed, it could be accomplished in a few minutes rather than the hours re-installing the application might take.
Using databases in conjunction with an application requiring multilingual support provided the kind of functionality and availability not found in previous solutions, and is presently in use. With the growth of the internet such support is even more critical now, as there can be dynamic requests for different languages (in the past there would typically be one language used per session) within a single page or session, and availability of application available on the internet must be as close to 24xc3x977 as technology can get.
The physical topology of a typical system that corresponds to the distributed multilingual support just described is shown in FIG. 1. It developed in parallel with the propagation of client-server applications and the tremendous expansion in the internet. The terminals used with centralized system topologies are no longer present. Instead, a client application is running on a client computer system shown as systems 100 and 102, or client a device shown as 104 and 106. Client machines are those known and standard in the art, including but not limited to IBM personal computers or IBM-PC clones running Microsoft Windows or NT running a standard web browser such as Internet Explorer or Netscape Navigator. Client devices include, but are not limited to, web connected phones which also have net interfaces and proprietary web browsers, or devices such as web-enabled televisions. When referring to clients in this disclosure, it will be understood that this includes machines and devices including but not limited to those just described. Clients or client devices include both the hardware and software of the device that is making a request through a network to a server.
Clients are operably connected to a network in standard ways well known in the art, including internet, WAN, or LAN interfaces. Network 108 is shown as a cloud, indicating it includes the interfaces and transport mechanisms well known in the art. Additionally, any number of clients may be connected to network 108, including more client systems as shown by the ellipses between client systems 102 and 104, and more client devices as indicated by the ellipses between client devices 104 and 106.
Server system 110 is also connected to the network 104 in ways well known in the art, including standard LAN, WAN, and internet connections. Server system 110 as a whole is of conventional design using well known components, including a hardware base and an operating system such as a Sun Microsystems Ultra 10 Model 333 Workstation running the Solaris v.7 operating system, and includes a server application program running on the system such as a web server. Technical details of the example system may be found on Sun Microsystems"" website.
The server application program may be a compiled program written in a language such as C, C++, or other well known language, or an interpreted application written in a language such as Perl. For the purposes of this disclosure when referring to a server it means a server system as just described including a standard hardware base, a standard operating system, and having the capability to fully support a server application program running on the server system so that the server application can make full and normal use of the system interfaces to the network 108 to which it is operably attached.
As is now common, server 110 is remotely located from database machines 114 and 116. Typically the database machines will be rackmounted and in close physical proximity to disk arrays, shown as disks 118 and 120 coupled to database machine 116, and disks 122, 124, and 126 coupled to database machine 116. Close physical proximity allows higher-speed connections to be made for better overall throughput, as is well known in the art. In larger companies or companies serving a large number of clients, there will be many servers in addition to the single one shown for illustrative purposes. The server application running on server 110 will access database machine 114 and/or 116 over network 112 as it needs to retrieve language-specific display fields for portions of any given user display.
Recently, the demands the server application program on server 110 makes on database machines 114 and 116 have increased significantly. This is due to several factors, but in particular the tremendous increase in the use of web-based servers which are typically accompanied with display pages having considerably more complexity than previous user interfaces. Even a simple user interface display page, shown as 200 in FIG. 2, can involve considerable text retrieval. Page 200 has two title fields, 202 and 204, each typically having multiple text strings at the top of the page. In addition there are a series of user-interactive fields with text strings in each shown as 206, 208, 210, and 212, with there being any practicable number of additional fields between 210 and 212. Fields 214, 216, 218, and 220 contain text strings that change according to the input provided by the user. There may be any practicable number of fields between 218 and 220. Each of the fields just listed will require server 110 to retrieve individual text strings from database machine 114 over network 112. In addition to the text string retrievals needed to initialize the page, as the user interacts with display fields 206 through 212 text strings will need to be continuously retrieved from database machine 114 for both the changing options in text fields 206 through 212 and the text in the fields coupled to the user input fields. As the user continues to interact with the server via the client, the network traffic and related delays in response between server 110 and the database machines 114 and 116 will continue.
Typically server 110 would not have the capability to handle the database on database machines 114 and 116. There are several critical reasons why server 110 cannot have a full database as exists on database machine 114 and 116. One is secondary storage considerations. Server 110 would typically not have enough secondary storage to download an entire database, as its primary function is to run server applications which require, overall, less secondary storage than database applications. Adding additional secondary storage is often not an option because of the extra space, cost, and complexity associated with the amount of storage a reasonably sized database would need. It is desirable that servers not be required to be directly connected to large disk arrays. Another critical reason servers do not have entire databases on them is based in system resource allocation. Servers need to be tuned to provide maximum throughput to clients who have outstanding requests. Resource contention within a server needs to be skewed towards its primary function, serving clients, at the expense of contending jobs such as a database manager if one were to be installed on server 110. This includes network I/O resources and bandwidth as well as peripheral storage throughput considerations.
Thus, at a time when it is necessary that the typical server be remote from the database machine, the number of interactions between the server application and the database machine is steadily rising. The results of this have probably been noted by most web-server usersxe2x80x94it can take a noticeable amount of time for a page to complete as it retrieves portions of its display. And is typical of current implementations, text string retrieved for current use are associated with specific fields in a specific page and are xe2x80x9clostxe2x80x9d (released, no longer used) after a new page is invoked or after a relatively short time period. Although there may be delays at several steps or links in the overall connection, it is now the case that the traffic between server 110 and database machine 114 over network 112 accounts for a measurable portion of it. This problem will continue to worsen as additional demands are made on servers.
Given the ever increasing demand on servers and the associated increase in database retrievals and the accompanying network traffic, there is an urgent need to find efficient ways of reducing the number of accesses a server makes with the database machine where text strings reside. This must be accomplished while maintaining the server and database machines as separate systems carrying out there primary tasks.
It is therefore a goal of this invention is to provide a method and system for reducing the amount of traffic between a server application and its associated database machine while providing dynamic multilingual support.
The present invention provides a system and method of use that allows a server application program to provide multilingual support to client programs without the need to be in regular contact with a remote multilingual database. The system includes a server and a server application program running on the server, where the server application program is designed to use language module files that are local, that is, can be accessed without going over a network. The language module file or files are specifically formatted to allow an interpreter to load them in as text string variables when a server application written in an interpreted language is being run. This provides both dynamic loading and use, unusually fast response, and freedom from the remotely located multilingual database.
The server application program determines the language being requested by the client by first parsing though the client""s request and looking for an explicit language indicator. If there is no explicit language request, the server application program will use a default language. The server application program may also make use of a history of language usage that corresponds to this request, session, or client. Such a history may be quite simple and limited for smaller applications and consist of a single default language choice. It may also be quite complex, keeping histories of clients and sessions that allow reasonably complicated heuristic searches to be performed to determine a language choice. As is well known in the art, any individual request from a client is part of a session (there may also be more than one session with a single client, depending on the client device). The methods used will depend on the complexity of expected use of the server application program, and the types and kinds of clients expected in each case.
As an option, the server program will generate requests for language module files from the multilingual database after determining a language requested by a client cannot be satisfied with locally available language module files. After receiving a language module file from a remote multilingual database, the server application program will make use of them locally.